-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Load cell gram scale #6729
base: master
Are you sure you want to change the base?
Load cell gram scale #6729
Conversation
The tests failed because of the numpy dependency. I guess I could move the check out of |
such a pity numpy is so bloaty and time consuming to just add it to requirements |
I'm not sure that this has a real world impact. I guess most, or at least a significant portion also use input shaping and have it installed anyway. |
i think its the sheer time to compile numpy is the issue if the host is sub par, it can take hours on some |
I would love to get on my "just require numpy" soap box (Binaries are installed automatically for 32bit, you don't need to compiling it. Its shockingly fast vs plain python. "Your job as a Python programmer is to write C") but... I want to ship this and be 'done' with the project. So what do I have to do? I can push the numpy require check back to the point where its clear that you are configuring a probe. Most of what I'm using it for in this PR ( For probing, I need |
Is there any way to provide / use a prebuilt v1.26 wheel? |
|
||
This document describes Klipper's support for load cells and load cell based | ||
probes. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not knowing what a load cell does/means for a 3d printer, could you add a sentence or two describing it's usage/benefits for 3d printers/klipper?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made some updates to the documentation including a little bit more exposition at the top and a section about how to read the load cell gram force
* Convert sensor counts to grams and make this available via unix socket and object status * Basic GCodes for tearing and reading the load cell * Guided Calibration * Diagnostic gcode to check the health of the load cell Signed-off-by: Gareth Farrington <[email protected]>
Signed-off-by: Gareth Farrington <[email protected]>
270aa4f
to
a3f6aa5
Compare
* Add API server load_cell/dump_force endpoint * Update [load_cell] config with calibration fields * Add G-Code commands for working with load cells * Add status reference for load_cell objects Signed-off-by: Gareth Farrington <[email protected]>
a3f6aa5
to
dde606a
Compare
For users: if you use Python 3.0 on a 32 bit RPI OS then PiWheels will just install a binary. That's the default behavior. You have to kinda work hard to not get that to happen. i.e. willfully use Python 2 or pick a 64 bit OS. For the git build system: I'm not sure how that works. |
PyPi has some arm64 wheels as well
There are examples of project who built the necessary wheels as CI actions. E.g. https://github.com/matrix-org/synapse/pull/14212/files Maybe it would be an option to built the needed wheels (Python 2 and Python3?) as Klipper CI and the install scripts (or KIAUH) could automatically draw upon them. |
This was updated to remove the numpy dependency |
# Load Cells | ||
|
||
This document describes Klipper's support for load cells. Basic load cell | ||
functionality can be used to read force data and to weigh things like filament. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider adding a note that weighing things is only possible on printers with the load cells in the bed, and not those with the cell in the extruder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want to get into applications because there are many. You don't even have to put it in the printer! Several people want to use this functionality to weigh filament spools mounted outside the printer. E.g. https://klipper.discourse.group/t/filament-spool-scale-hx711/19800/
- You could check before a print if there is enough filament on the spool based on the print weight
- Track filament used by weight.
- Track drying if the filament by weight lost
In the future this may be in an application that is just a dry box and not even a printer.
One community member is even working on runout detection in a resin printer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Sorry for the delay in responding.
In general it seems fine to me. I have a few comments and questions - see below.
Cheers,
-Kevin
### load_cell/dump_force | ||
|
||
This endpoint is used to subscribe to force data produced by a load_cell. | ||
Using this endpoint may increase Klipper's system load. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems odd that there is an additional endpoint added for this information. I would have thought the information could be added to the existing hx71x/dump_hx71x
endpoint (or that endpoint replaced with this one).
`{"id": 123,"result":{"header":["time", "force (g)", "counts", "tare_counts"]}}` | ||
and might later produce asynchronous messages such as: | ||
`{"params":{"data":[[3292.432935, 40.65, 562534, -234467]]}}` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just out of curiosity, does "tare_counts" change with each sample?
#reverse: | ||
# Reverses the polarity of the load cell. This is a boolean value, the | ||
# default is False. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, is "reverse" effectively the same as a negative "counts_per_gram"?
### LOAD_CELL_DIAGNOSTIC | ||
`LOAD_CELL_DIAGNOSTIC [LOAD_CELL=<config_name>]`: This command collects 10 | ||
seconds of load cell data and reports statistics that can help you verify proper | ||
operation of the load cell. This command can be run on both calibrated and | ||
uncalibrated load cells. | ||
|
||
### CALIBRATE_LOAD_CELL | ||
`CALIBRATE_LOAD_CELL [LOAD_CELL=<config_name>]`: Start the guided calibration | ||
utility. Calibration is a 3 step process: | ||
1. First you remove all load from the load cell and run the `TARE` command | ||
1. Next you apply a known load to the load cell and run the | ||
`CALIBRATE GRAMS=nnn` command | ||
1. Finally use the `ACCEPT` command to save the results | ||
|
||
You can cancel the calibration process at any time with `ABORT`. | ||
|
||
### TARE_LOAD_CELL | ||
`TARE_LOAD_CELL [LOAD_CELL=<config_name>]`: This works just like the tare button | ||
on digital scale. It sets the current raw reading of the load cell to be the | ||
zero point reference value. The response is the percentage of the sensors range | ||
that was read and the raw value in counts. | ||
|
||
### READ_LOAD_CELL load_cell="name" | ||
`READ_LOAD_CELL [LOAD_CELL=<config_name>]`: | ||
This command takes a reading from the load cell. The response is the percentage | ||
of the sensors range that was read and the raw value in counts. If the load cell | ||
is calibrated a force in grams is also reported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a general comment, it's generally preferable to implement less commands. For example, could this be reduced to just two commands: LOAD_CELL_READ (for reading and diagnostics) and LOAD_CELL_CALIBRATE (for calibrating and changing the tare).
@@ -0,0 +1,102 @@ | |||
# Load Cells |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a new document is added then it's also necessary to update docs/Overview.md and docs/_klipper3d/mkdocs.yml
# Adapter for WebhooksHelper that transforms the response using a function | ||
# Anything that implements the add_client contract can be a message source | ||
# Outputs to its own clients | ||
class WebhooksTransformer(WebhooksHelper): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you elaborate on what this does (as well as WebhooksHelper)?
At first glance, it seems a little odd to make a slightly different interface for just loadcell. If the BatchWebhooksClient code isn't flexible enough, maybe we should expand the webhooks interface and refactor the other users (like ldc1612 and accelerometers).
self.printer.send_event("load_cell:calibrate", self) | ||
if self.is_tared(): | ||
self.printer.send_event("load_cell:tare", self) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you elaborate on what these events will be used for?
This PR adds the features needed to make a load cell actually work as a gram scale. This PR will let you weight filament or measure a force in grams. (no homing or probing yet!)
counts
to grams and make this force data available via unix socket and printer object statusThis code has been tested by several people in the community and some last minute bug fixes and changes were landed:
reverse
option allows the polarity of the force readings to be inverted. You can have your probing collision graphs in either orientation now.reference_tare_counts
is written to config and read as an integer. linkCALIBRATE
was used beforeTARE
A lot of work (months) and bug fixing went into parts of this, particularly
LOAD_CELL_DIAGNOSTIC
and theLoadCellSampleCollector
. These bits have to work when the sensor is buggy and still produce usable output.LoadCellSampleCollector
also underpins later work for probing.numpy
is required for this PR. We could change that. But PR's for probing will absolutely need it. If you want to merge[load_cell]
and[load_cell_probe]
then it seems there is no point in trying to keep it out of this PR.